Prior art which is related to this technical field can e.g. be found in the technical specifications TS 23.216 (current version: 11.1.0) and TR 23.885 (current version 1.4.0) of the 3GPP, as well as the permanent reference documents IR.88 (current version: 4.0) and IR.92 (current version: 4.0) of the GSMA.
The following meanings for the abbreviations used in this specification apply:
2G: 2nd Generation
3G: 3rd Generation
3GPP: 3rd Generation Partnership Project
APN: Access Point Name
ATCF: Access Transfer Control Function
CS: Circuit Switched
DL: Downlink
DTM: Dual Transfer Mode
EDGE: Enhanced Data Rates for GSM Evolution
eNB: evolved NB
EPS: Evolved Packet System
E-UTRAN: evolved UTRAN
GBR: Guaranteed Bit Rate
GERAN: GSM EDGE Radio Access Network
GPRS: General Packet Radio Service
GSM: Global System for Mobile Communication
GSMA: GSM Association
HO: Handover
HSPA: High Speed Packet Access
IMS: IP Multimedia Subsystem
IMEI: International Mobile Equipment Identity
IMSI: International Mobile Subscriber Identity
IP: Internet Protocol
ISDN: Integrated Services Digital Network
LTE: Long Term Evolution
LTE-A: LTE-Advanced
MBR: Multiple Bit Rate
MME: Mobile Management Entity
MSC: Mobile Switching Center
MSISDN: Mobile Subscriber ISDN Number
NB: Node B
PCC: Policy and Charging Control
PCRF: Policy and Charging Rules Function
P-CSCF: Proxy Call State Control Function
PDN: Packet Data Network
PDP: Packet Data Protocol
P-GW: PDN Gateway
PS: Packet Switched
QCI: QoS Class Identifier
QoS: Quality of Service
RAI: Routing Area Identity
RAN: Radio Access Network
RAT: Radio Access Technology
RTCP: RTP Control Protocol
RTP: Real Time Protocol
SGSN: Serving GPRS Support Node
S-GW: Serving Gateway
SIP: Session Initiation Protocol
SRVCC: Single Radio Voice Call Continuity
TFT: Traffic Flow Template
TMSI: Temporary Mobile Subscriber Identity
UE: User Equipment
UL: Uplink
UTRAN: Universal Terrestrial Radio Access Network
VoIP: Voice over IP
XCAP: XML Configuration Access Protocol
XML: Extensible Markup Language
In the specification release 8 of the 3GPP the specification for supporting SRVCC from E-UTRAN/HSPA to UTRAN/GERAN direction has been defined. Supporting SRVCC in the other direction (which may be called reverse SRVCC) has been studied by the 3GPP in specification document TR 23.885, and one of the alternatives mentioned therein was recommended for standardization in Release 11.
A solution proposal for normative work assumes that P-GW, PCC and source SGSN do not need to be impacted and the voice media is sent using default bearer immediately after reverse SRVCC (“rSRVCC”) until UE setups the QCI 1 bearer.
However, the recommended solution has a few open areas that would need closure.
For example, in the recommended access transfer procedure (see specification document TR 23.885, section 6.3.3.7.5 of version 1.4.0), the document shows call flows for the non DTM case and for the DTM case according to FIGS. 1 and 2 (FIG. 1: Access Transfer Preparation Alternative 5, non-DTM case; FIG. 2: Access Transfer Preparation Alternative 5, DTM case).
Accordingly, the call flow for the case shown in FIG. 1 is as follows, as specified by documents TR 23.885:
1. The RNC/BSC sends a “HO required” message to the MSC Server including an indication that this HO is for rSRVCC. If the MSC Server is the target MSC, it forwards the “HO required” message to the anchor MSC Server.
2. The MSC Server sends a “SRVCC CS to PS HO request” message to the Target MME. If required, the IMSI is provided for identifying the UE.
3. The MSC Server sends an “Access Transfer Notification” message to the ATCF, e.g. a SIP “re-INVITE” or “INVITE” message, which indicates the ATCF that it should prepare for the transfer of media to PS. The ATCF allocates media ports on the ATGW. The media ports and codecs allocated by the ATCF are provided to the MSC Server in the response message. This step is independent of step 2. It is to be noted that the ATCF retrieves the ports/codecs received from the UE in its IMS registration. The ATCF is able to correlate the IMS registration made by the UE and the one made by the MSC Server on behalf of the UE for instance based on the C-MSISDN or on the IMEI derived instance-id used by both those registrations. It is further to be noted that the Access Transfer Notification message could e.g., be implemented using an “INVITE” or other appropriate message. This is for further study.
4. If the MME has no UE context it sends a “Context Request” message using P-TMSI and RAI to find the old SGSN.
5. The SGSN responds with “Context Response” message including all UE contexts.
6. The Target MME allocates resources in E-UTRAN.
7. A “SRVCC CS to PS HO response” message is returned from the target MME to the MSC Server.
8. The MSC Server sends a “HO required Ack” message to the RAN, possibly via the target MSC, and the RAN sends a “HO command” to UE, indicating CS to PS handover. The MSC Server also includes in that message the IP address/ports and selected codecs for the ATGW.
9. In case of an ATCF with media anchored in ATGW, the MSC Server sends an “Access Transfer Preparation Request” message, e.g. a SIP “re-INVITE” or “PRACK” message, to the ATCF to trigger the ATCF/ATGW to have the media path switched to the IP address/port of the UE on the target access. In case of an ATCF without media anchored in ATGW, the MSC Server sends an “Access Transfer Preparation Request” message to ATCF and the media path between ATCF/ATGW and the MSC Server/MGW is to be established.
10. The UEs send a “Handover confirmation” message to the eNB.
11. The eNB sends a “Handover Notify” message to the MME.
12. The MME sends a “Modify Bearer Request” message to the SGW, which is forwarded to the PGW to update PS bearer contexts.
13. The MME sends the “Acknowledgment to the Context Response” message to the SGSN.
14. The voice media is started directly. It is to be noted that during a short period of time prior the RAT has been changed and the new bearer has been established, the media will be sent over the default bearer.
15. The UE initiates the session continuity procedures according to clause 6.3.3.8 of the specification document TR 23.885 (version 1.4.0) towards the ATCF.
16. As a result of the session continuity procedures, the bearer setup is performed (initiated by the P-CSCF).
17. The voice media is sent in the dedicated bearer.
Furthermore, the call flow for the case shown in FIG. 2 is as follows, as specified by documents TR 23.885:
The step 1 is the same as described above with reference to FIG. 1.
1a. But in the DTM case the UE is already active in PS domain, and the RNC/BSC sends also a “Relocation Required” message to source SGSN.
Then, steps 2 and 3 are the same as described above in connection with FIG. 1.
4. The Source SGSN sends “Relocation Request” message to the target MME.
5. The Target MME allocates resources in E-UTRAN.
6a. A “relocation response” message is returned to the Source SGSN.
6b. The Source SGSN sends a “HO Required Ack” message to RAN.
Thereafter, steps 7 to 11 are the same as described above in connection with FIG. 1.
12. The MME sends a “Forward relocation Complete” message to the old SGSN.
13. The MME sends a “Modify Bearer Request” message to the SGW which is forwarded to the PGW to update PS bearer contexts.
Eventually, steps 14 to 17 are again same as described above in connection with FIG. 1.
Accordingly, the above may be summarized in that some high level principles used for voice bearer switching are:
1. The UE is using CS bearer in 2G or 3G CS access for voice media, but UE has also PDP context used for IMS registration and SIP/XCAP signalling. The used PDP context is Primary PDP context to IMS APN (wherein it is to be noted that a Primary PDP context cannot have TFT).
2. SRVCC from 2G/3G CS to LTE is triggered by source radio and UE is handed over to LTE (above steps 1 to 10) and CS bearer is released.
3. After handover the voice continues in the LTE access, but there is only default bearer for IMS APN, which is used for both IMS signalling and voice media (see step 14 above).
4. The network creates, based on the IMS voice session negotiation, a dedicated EPS bearer including QCI 1, GBR/MBR and voice media packet flow information (see steps 15-16 above).
5. The UE puts voice media into established dedicated bearer for uplink direction. Similarly, the P-GW maps downlink traffic (step 16-17).